經過七天的準備，從需求分析、User Story 拆解、介面設計到驗收標準定義，今天終於要進入 AI-DLC Sprint 的核心環節 - AI Developer。這不是傳統的「寫程式」階段，而是一個全新的協作模式，AI 成為真正的開發夥伴。

從 Copilot 到真正的 AI Developer

還記得第一次用 GitHub Copilot 時的驚喜嗎？寫個註解，程式碼就自動出現。但很快你就會發現它的限制 - 缺乏上下文、不懂業務邏輯、無法把握整體架構。

在 MenuBar Todo 的開發中，我體驗到了完全不同的 AI Developer。它不只是程式碼生成器，而是能理解我們前七天所有準備工作的開發夥伴。

傳統 Copilot vs AI Developer

傳統 Copilot 模式：

我：// 新增任務功能
Copilot：[生成一個通用的 addTask 函數]
我：不對，要考慮空白輸入
Copilot：[重新生成]
我：還要處理重複提交...
(來回修改 10 次)

AI Developer 模式：

我：實作 US-3.3 的快速新增任務功能
AI：我看到這個 Story 有 7 個驗收條件，包含空白驗證、
    連續輸入、特殊字元處理等。讓我基於這些 AC 來實作...
    
[直接生成符合所有 AC 的完整實作]

差別在於，AI Developer 記得我們的需求文件、設計決策、測試標準，它是基於完整上下文在開發，而不是猜測你要什麼。

層次化的程式碼生成策略

與 AI 協作開發 MenuBar Todo，我採用了三層次的生成策略，從宏觀到微觀逐步推進。

第一層：專案架構生成

當我告訴 AI：「基於我們的 MenuBar Todo 設計，建立 Electron + React 專案結構」，它不是套用模板，而是基於我們的具體需求生成：

專案結構不只是資料夾，而是體現了架構決策：
- /src/main (Electron 主程序)
  - tray.ts (Menu Bar 整合)
  - window.ts (視窗管理)
  - store.ts (資料持久化)
  
- /src/renderer (React 渲染程序)
  - /components (展示元件)
  - /hooks (業務邏輯)
  - /store (狀態管理)
  
- /src/shared (共用邏輯)
  - /types (TypeScript 定義)
  - /utils (工具函數)

每個檔案都有明確的職責，符合我們定義的領域模型。這不是 Google 來的範例，而是為 MenuBar Todo 量身定制的架構。

第二層：功能模組生成

在模組層，AI 負責將 User Story 轉化為具體實作。以「快速新增任務」為例：

AI 不會直接寫一個巨大的元件，而是先提出模組規劃：

• QuickAddInput (輸入介面元件)
• useTaskCreation (任務創建邏輯)
• taskValidator (輸入驗證)
• dateParser (自然語言解析)

每個模組都對應到特定的 AC，可以獨立開發和測試。

第三層：細節實作生成

這是最容易出錯的地方。我的經驗是「步進式生成」：

步驟一：骨架
先生成函數簽名和基本結構，確認介面設計正確。

步驟二：核心邏輯
實作主要功能，先不管邊界情況。

步驟三：錯誤處理
加入各種異常處理，對應到 AC 中的 Edge Case。

步驟四：優化
效能優化、程式碼簡化、加入註解。

這種分層策略讓每個階段都可以驗證，錯誤不會累積。

AI Pair Programming 的角色切換

與 AI 結對編程最有趣的是動態角色切換，根據不同情況選擇最適合的協作模式。

模式一：AI 主導開發

當處理大量重複性工作時，讓 AI 當 Driver：

場景：為所有元件加入深淺色主題支援

我：所有元件都要支援深淺色主題切換，
    使用 Tailwind 的 dark: 前綴
    
AI：了解，我會：
    1. 先建立主題 Context
    2. 更新所有元件的 className
    3. 加入主題切換邏輯
    4. 處理系統主題偵測
    
    開始執行...

我只需要提供高層指導，AI 處理所有細節。這時我可以專注在檢查業務邏輯，而不是寫樣板程式碼。

模式二：人類主導開發

處理核心業務邏輯時，我寫程式碼，AI 當 Reviewer：

場景：實作任務優先級算法

我：[寫了一個複雜的排序邏輯]

AI：我注意到幾個潛在問題：
    1. 當 dueDate 為 null 時會報錯
    2. 優先級相同時沒有次要排序
    3. 這個算法是 O(n²)，可以優化到 O(n log n)
    
    要我提供改進建議嗎？

AI 的建議是參考，不是命令。我可以選擇接受或解釋為什麼要這樣設計。

模式三：協同解決問題

遇到困難問題時，與 AI 一起思考：

場景：Electron 視窗定位問題

我：視窗有時會超出螢幕邊界

AI：讓我們一起分析：
    1. Tray 圖標可能在螢幕邊緣
    2. 多螢幕環境的座標系統不同
    3. Windows/Mac/Linux 行為差異
    
    建議先取得螢幕邊界，然後...
    
我：對，但 Mac 的 Menu Bar 在頂部...

AI：好點！那我們需要分平台處理...

這種協同模式下，AI 不只是工具，更像是會思考的夥伴。

從 AC 到程式碼的智慧轉換

最精彩的是看 AI 如何將昨天定義的 AC 轉化為程式碼。

Given-When-Then 的程式碼映射

拿「連續輸入」的 AC 為例：

AC 定義：

Given 輸入欄位已聚焦
When 快速連續輸入 3 個任務
Then 3 個任務都成功創建，無重複提交

AI 生成的程式碼結構：

// Given -> 初始化
const [isInputFocused, setInputFocused] = useState(true)

// When -> 防抖處理
const debouncedSubmit = useMemo(
  () => debounce(handleSubmit, 100),
  []
)

// Then -> 驗證邏輯
const verifyNoDoubleSubmit = (tasks) => {
  const uniqueIds = new Set([tasks.map](http://tasks.map)(t => [t.id](http://t.id)))
  return uniqueIds.size === tasks.length
}

不是生硬的翻譯，而是理解意圖後的智慧實作。

TDD 循環的 AI 加速

在 TDD 模式下，AI 讓紅-綠-重構循環變得超快：

紅燈（2分鐘）
AI 根據 AC 生成測試案例，確保測試會失敗。

綠燈（3分鐘）
AI 生成最小可行實作，只求通過測試。

重構（2分鐘）
AI 優化程式碼結構，保持測試通過。

原本 30-60 分鐘的 TDD 循環，現在 7-8 分鐘就完成。關鍵是 AI 理解了 TDD 的精神 - 不是為了寫測試而測試，而是用測試驅動出更好的設計。

Spec-Driven Development 的完美實踐

還記得我們花了七天準備的所有文件嗎？現在終於看到價值了。

規格的力量

因為我們有清晰的規格：

• User Story 定義了「要做什麼」
• AC 定義了「怎樣算完成」
• 設計稿定義了「長什麼樣子」
• 測試案例定義了「如何驗證」

AI Developer 可以基於這些規格，幾乎自主地完成開發。我只需要在關鍵決策點介入。

監督而非編碼

我的角色從「寫程式的人」變成「確保品質的人」：

• 檢查業務邏輯是否正確
• 評估技術方案是否合理
• 把關程式碼品質標準
• 處理 AI 無法決策的部分

這不是偷懶，而是更高效的分工。人類做人類擅長的（思考、決策），AI 做 AI 擅長的（執行、生成）。

實戰心得：AI Developer 的三個境界

第一境界：工具

把 AI 當成進階的程式碼補全工具，省打字時間。

第二境界：助手

AI 理解你的意圖，能生成完整功能，但需要大量指導。

第三境界：夥伴

AI 理解整個專案脈絡，能主動提出建議，甚至挑戰你的決定。

MenuBar Todo 的開發讓我真正體驗到了第三境界。當 AI 說「這個設計不符合你在 Day 3 定義的原則」時，我知道它不只是工具，而是真正的開發夥伴。